As per description on Istio website, Service mesh is used to describe the network of microservices that make up applications and the interactions between them. As a service mesh grows in size and complexity, it can become harder to understand and manage. Its requirements can include discovery, load balancing, failure recovery, metrics, and monitoring. A service mesh also often has more complex operational requirements, like A/B testing, canary rollouts, rate limiting, access control, and end-to-end authentication.
Simply put, a service mesh is an extra layer of software that is deployed alongside your cluster (e.g. Kubernetes). In other words, all network traffic running between the services in our cluster is routed through the service mesh software.
Service mesh can be implemented in various ways, Istio is one of them.
Overview
Istio lets you connect, secure, control, and observe services.
It is a completely open source service mesh that layers transparently onto existing distributed applications. Istio’s diverse feature set lets you successfully, and efficiently, run a distributed microservice architecture, and provides a uniform way to secure, connect, and monitor microservices.
Architecture
Istio implements service mesh by injecting its own container in each pod, a proxy where mesh logic is implemented. Now, when container in microservice 1 is making a call to container in microservice 2, it is routed via the proxies in each of the pods. Furthermore, microservice 2 may be calling microservice. Following picture shown the flow.
This is achieved by configuring the IP tables at each pod so that container thinks that it is making a remote call but in reality, it is just calling th proxy at local host. Proxy injects the mesh logic and relays the call to target proxy, which in turn relays the call to target container.
The proxies are collectively called the Data Plane in Istio. Rest of the software in Istio is called the Control Plane. Some of the functionalities of control plane are shown below.
All of this is achieved by simply two steps:
- Label namespace where Istio needs to automatically inject sidecar proxy into the pods.
- Start application in this namespace.
Data Plane
Istio data path consists of set of proxies deployed as sidecars. These proxies mediate and control all network communication between microservices along with a control plane component Mixer.
Istio proxy is an open source proxy Envoy, written by Lyft.
Why do we need Istio
Lots of the features supported by Istio are already available in Envoy. Envoy is agnostic to any cluster management system e.g. Kubernetes and hence Envoy has its own terminology to use these features.
This is where Istio shines. It simplifies Envoy because
- Istio understands Kubernetes
- You can use regular Kubernetes YAML, via Custom Resource Definition(CRDs), which gets transformed into Envoy configuration automatically.
Control Plane
Control plane manages and configures the proxies to route traffic. Additionally, control plane configures Mixer to enforce policies and collect telemetry.
The control plane is consisted of:
-
Galley reads in Kubernetes yaml and transforms it into an internal structure that Istio understands. This makes Istio work with non Kubernetes environment (such as Consul).
-
Pilot converts the configuration from Istio internal structure into a format that proxy (Envoy) understands. It is also responsible for propagating configuration to the proxies.
-
Citadel manages certificates to enable TLS/SSL across the entire cluster.
-
Mixer is a general purpose telemetry and policy hub.
Portability
Istio implementation is “Cluster agnostic” i.e. you can move from Kubernetes to another cluster management system. It can be done by taking Istio configuration and use on other management system. As of now, Istio supports
- Services deployment on Kubernetes
- Services registered with Consul
- Services running on individual virtual machines